What do you think about something like this?

That way we don't have to copy files around to be used in a later step. I think that would also allow users to consume it and could write the file contents to Slack or an email or something without having to worry about where the file is located. I think that's true anyway.

Then later we can do:

if [ -f "${{ steps.run.outputs.receiptFile }}" ]; then
...
fi

To expose the file outside of the composite action, we would also need to declare it as an extra output there.
We could do that but my intention is exactly opposite as described there

The receipt file is renamed to a predictable receipt.txt file to avoid passing the filename across steps and adding an attack surface as the file content is archived and inlined in the GitHub summary

We also could keep the reference .data/01-validate-incremental-building/latest/exp1-*.receipt in the 3 different steps to avoid the copy
The copy is just there to avoid repeating the uneasy reference.
Do you think it would be better?

To expose the file outside of the composite action, we would also need to declare it as an extra output there.

Right, I knew there was something I was missing. I would do that.

adding an attack surface as the file content is archived and inlined in the GitHub summary

I don't get this part.

Having as a step input a file path which you then display in the summary and upload as an artifact is something I am a bit reluctant to do
I see this as a way to display content of a file which was not meant to be displayed in the first place

Sorry, but I still don't understand. We already displayed the content in the summary before here.

And the file was an input to the upload action here.

The artifact is uploaded immediately after the experiment completes in the following step and the summary is written immediately after that. All of this happens within the composite action so the user can overwrite the file, but neither the uploaded artifact or experiment summary should be affected.

In any case, they could have overwritten the file before these changes too.

I agree that the risk is limited or not worsened but I still feel it is bad practice to display a file content without controlling how the file path is obtained

Is your concern only about exposing the file path to the user, i.e., adding it as an output of the composite action?

My concern is that the composite step is displaying a file which could potentially be something else than the report.
You could think of a scenario with a complex consuming workflow, calling this composite, with maintainers thoroughly checking that files with secrets are not undisclosed by a PR, but omitting to control the behavior of steps brought by composite actions.
This is unlikely to happen but not impossible if we make the receipt file a step input/output

We agreed on a call to inline the full receipt path when used

Isn't RECEIPT_FILE undefined now?

damned, I missed this one, good catch. I'll fix it in another PR

You could just move the capturing of build scan links to the Fill GitHub summary step inside of the if condition such that the final thing done in this step is the script invocation. That would also allow you to remove the set +e and capturing of the exit code.

That makes sense and will put altogether the GitHub I/O in the same step 👍